Hi @ncode, awesome! This goes definitely in the right direction!

Some thoughts so far but theses are things we also could stabilise later:

• the token resolution provides additional context, e.g. policies afaik, should we pass those to the webhooks as well?
• afaik X-... headers are discouraged, should we use NACP-.... ?
• passing everything as headers might get a bit messy in cases there will be more values, we could break the API so far and pass it as a combined document to the webhook ´{ job: , context : { remote_ip_addr: ..., ... }}`

I'm also currently waiting for a recommendation from the OPA communityhow to model this there

Hi @mxab,

Hi @ncode, awesome! This goes definitely in the right direction!

Some thoughts so far but theses are things we also could stabilise later:

• the token resolution provides additional context, e.g. policies afaik, should we pass those to the webhooks as well?

I didn't think of it but it's a pretty nice idea to pass all the available information since we've already resolved it :)

• afaik X-... headers are discouraged, should we use NACP-.... ?

Yes. Let's use NACP-...

• passing everything as headers might get a bit messy in cases there will be more values, we could break the API so far and pass it as a combined document to the webhook ´{ job: , context : { remote_ip_addr: ..., ... }}`

I agree that passing the context like you describe will make things a bit more flexible, specially with the extra metadata from the token it will be cleaner. I'm only in doubt about X-FORWARD-FOR and the NACP-Nomad-Accessor-ID, these would be useful to have available as readers without the need to parse the content. What do you think?

I'm also currently waiting for a recommendation from the OPA communityhow to model this there

Nice!

Sorry for the late response.

X-FORWARD-FOR and the NACP-Nomad-Accessor-ID, these would be useful to have available as readers without the need to parse the content

Ah so if I get you correctly your "validation" part in this case is solely on the Client IP Address + Accessor ID. Yeah I guess it makes sense.

Regarding the OPA part, they recommended to create an input consisting out of the context and the job. So I guess we need to update this part here and create a input struct the consists out of a caller context (client ip addr, resolved token) and the job

So for the remote hooks I think it make sense to use the same structure, we could still leave the headers as well so it works for your use case

Sorry for the late response.

No worries!

X-FORWARD-FOR and the NACP-Nomad-Accessor-ID, these would be useful to have available as readers without the need to parse the content

Ah so if I get you correctly your "validation" part in this case is solely on the Client IP Address + Accessor ID. Yeah I guess it makes sense.

Regarding the OPA part, they recommended to create an input consisting out of the context and the job. So I guess we need to update this part here and create a input struct the consists out of a caller context (client ip addr, resolved token) and the job

So for the remote hooks I think it make sense to use the same structure, we could still leave the headers as well so it works for your use case

Deal! I will start working on it this weekend!

Hi @mxab,

I think at this stage we have the bare bones of how to propagate the data. Now I'm staring to add the context passing to mutators and validators. I will add those to the same PR and we can break it into different pieces if it's a too big of a PR. One thing I'm not entire sure is if we should break the api and have:

type Payload struct {
	Job     *api.Job               `json:"job"`
	Context *config.RequestContext `json:"context,omitempty"`
}

I will add a few extra tests and deploy a release to test this week to validate in production :)

Hi,
Nice. I'll review it asap, just a bit stuffed until the weekend.

Hi, Nice. I'll review it asap, just a bit stuffed until the weekend.

No worries!